Augmenting Programming Languages with a Type System

ABSTRACT

Described is a technology by which metadata augments a programming language such as JavaScript. Software components such as application programming interfaces are associated with metadata. When a software component is selected for use, such as when putting together a computer program in a graphical programming environment, its corresponding metadata is accessed. The metadata may be used to validate the usage of the software component, such as to validate a constraint associated with a value, provide a default value, validate a value&#39;s type, and/or determine whether a value is required. Validation may also determine whether data output by one software component is of a type that is appropriate for input by another software component. In addition to validation via type metadata, the metadata may provide descriptive information about the selected software component, such as to assist the programmer and/or provide further information to the programming environment.

CROSS-REFERENCE TO RELATED APPLICATIONS

The application is a continuation of, claims the benefit of and priorityto, previously filed U.S. patent application Ser. No. 12/122,021entitled “Augmenting Programming Language with a Type System” filed onMay 16, 2008, the subject matter of which is hereby incorporated byreference in its entirety.

BACKGROUND

Dynamic programming (e.g., scripting) languages are commonly used byprogrammers to produce code. JavaScript (also referred to as ECMAScriptor JScript) is a well-known example of one such programming languagewidely used on the web, and is valued for its flexibility andsimplicity. Much of that flexibility is derived from the fact thatJavaScript is dynamically-typed, which means that programmers do nothave to declare the types of their variables in their programming.Instead, the JavaScript engine attempts to treat whatever variable theprogrammer is using as the data type that makes the most sense in thecontext in which it is being used.

However, despite this flexibility, there are drawbacks to such adynamically-typed language. For one, some data values are ambiguous;dynamic typing makes it more difficult for programmers and runtimes todifferentiate between such ambiguous values, and to do parametervalidation and matching. By way of example, the value ‘98052’ maycorrespond to an integer or a string, as well as possibly correspondingto a higher-level concept like a zip code. In such an example, dynamictyping has no way to determine the value's intended type.

SUMMARY

This Summary is provided to introduce a selection of representativeconcepts in a simplified form that are further described below in theDetailed Description. This Summary is not intended to identify keyfeatures or essential features of the claimed subject matter, nor is itintended to be used in any way that would limit the scope of the claimedsubject matter.

Briefly, various aspects of the subject matter described herein aredirected towards a technology by which sets of metadata are associatedwith programming language code components, such as applicationprogramming interfaces, with a corresponding set of metadata accessedwhen a selected programming language code component is used. Theselected set of metadata may be used to validate the usage of theselected programming language code component, e.g., to validate aconstraint associated with a value, providing a value with default data,validate a value's type, and/or determine whether a value is required.Validation may also determine whether data output by one component is ofa type that is appropriate for input by another component. In additionto validation, the metadata may provide descriptive information aboutthe selected programming language code component.

In one example implementation, programming code is developed via a userinterface, such as by dragging representations (icons) of softwarecomponents onto a design surface; such placement may be detected. For apart of the programming code (e.g., corresponding to the softwarecomponent), the corresponding set of metadata, which may be XML, isselected and used to ensure that the software component properlyexecutes. For example, when a software component having a definedinterface is coupled to another software component, the compatibility ofthe input and output data may be checked. As another example,descriptive metadata or type system metadata may be used at runtime toensure proper execution.

Other advantages may become apparent from the following detaileddescription when taken in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and not limitedin the accompanying figures in which like reference numerals indicatesimilar elements and in which:

FIG. 1 is a block diagram representing example components in aprogramming environment for augmenting a programming language withmetadata including type system metadata.

FIG. 2 is a flow diagram showing example steps taken to use type and/ordescriptive metadata associated with programming language code.

FIG. 3 is a representation of a user interface showing one example usageof augmenting a programming language with type system metadata.

FIG. 4 shows an illustrative example of a computing environment intowhich various aspects of the present invention may be incorporated.

DETAILED DESCRIPTION

Various aspects of the technology described herein are generallydirected towards using a metadata system (e.g., XML-based) to augment aprogramming language (e.g., the JavaScript/ECMAScript/JScript language)with an explicit capability and type system that need not rely oninference. As will be understood, the use of such metadata addssignificant depth to the basic programming language typing mechanisms.By way of example, with such metadata, programmers, the programmingenvironment and/or the application runtime can determine the data typesof data values (e.g., parameters, return types or fields, notnecessarily numeric), establish whether a data value is optional orrequired, provide constraints on data values, and so forth. Further,documentation based upon the metadata may be provided, such as todynamically assist a programmer when programming.

While many of the examples described herein are directed towardsXML-based metadata and the JavaScript/ECMAScript/JScript language, it isunderstood that these are only examples. Indeed, other metadata formatsand languages may benefit from the technology described herein. Further,while the examples are directed towards a graphical user interfaceprogramming environment, any way of entering code and/or metadata,including via text with embedded comments, may be used. As such, thepresent invention is not limited to any particular embodiments, aspects,concepts, structures, functionalities or examples described herein.Rather, any of the embodiments, aspects, concepts, structures,functionalities or examples described herein are non-limiting, and thepresent invention may be used various ways that provide benefits andadvantages in computing in general.

Turning to FIG. 1, there is shown a general block diagram representingexample components in a programming environment 102 in which metadata isused to augment a programming language. Note that in the exampleimplementation generally represented in FIG. 1, a developmentenvironment 104 and a runtime environment 106 are shown in theprogramming environment 102 as being tightly linked to one another,although this is not necessary, e.g., development may occur separately,such as well before the program is run. In any event, for simplicity,the term “programming environment” is used herein to represent thedevelopment environment 104 or the runtime system 106 that executes arunning application, however coupled. The development environment 104 orruntime environment 106, or both, may be hosted in a web browser, forexample.

In the development environment 104, the exemplified metadata includestype data 110 and descriptive data 112, although as described below thetype data 110 and descriptive data 112 may be merged into a single datastructure, (e.g., file), as represented in FIG. 1 via the dashed line.In a visual development environment, the programmer has a user interface114 with which to interact, such as to select a software component (alsoreferred to as a block) from a set of reusable components 116, e.g.,interfaces such as APIs, functions and so forth. For example, thecomponents may correspond to classes each containing a collection ofinterfaces, but a component also may be an individual function or thelike. The programmer may interconnect such components, e.g., to linkinterfaces together. Each component, or individual interfaces, may havean associated set of one or more metadata files.

In general, the type system metadata 110 defines a specific set of typesthat can be used with each component, such as to enable enhanced typematching relative to the basic type matching provided by the engine(e.g., the JavaScript engine). More particularly, based on the typedata, type rules/logic 120 or the like may perform tasks such as toperform parameter validation and matching. For example, the rules/logic120 may ensure that that output data of one interface is compatible withthe input data of another interface to which it is connected, such as tonotify the programmer of any mismatch, and/or transparently insert codethat converts one output type to an appropriate type for input withoutthe programmer's intervention. Other actions include enforcingconstraints (e.g., ensuring a value is within a range, is present whenrequired, is non-zero, is positive, and/or many others), set defaultvalues, and so forth.

Also represented in FIG. 1 is the runtime system 106, which takes from aruntime preparation system 128 program metadata 130 and (optionally)executable code 132. Note that the runtime system 106 can operate onexecutable code, e.g., directly, or operate on program metadata via aninterpreter 134; an engine (implicit) runs the interpret or theexecutable code. The runtime 106 may use the type system metadata 110and/or the descriptive metadata 112, (or a copy thereof) represented bythe labels 112 c and 110 c.

Note that although not shown, in one alternative the runtime system 106may input pre-compiled code and compile it into executable code; thecode may be run as it is compiled, e.g., via a just-in-time (JIT)compiler, may be converted to an intermediate language (e.g., .NET MSIL)or the executable code may be stored for running at some later time, andso forth. The metadata may be useful across languages, e.g., C+, C##and/or JavaScript.

In addition to improving programming and results based upon associatedtype metadata, the descriptive metadata 112 may be provided and used. Ingeneral, descriptive metadata 112 is used by the programming environment102 to provide high-level guidance to itself, and to the developer aboutthe kinds of things that the component is capable of doing. For example,descriptive metadata can describe a list of operations that thecomponent offers, a brief description of the code that may be used toautomatically generate documentation, or a set of default values thatthe programming environment will load when the component is called. Forexample, instead of selecting a component by name, a programmer canpossibly search among components by their features, view a tooltipand/or other descriptive output data by hovering over a component to seewhat the component does, and so forth.

In one example implementation, a standard XML schema defines thedescriptive metadata and the type system metadata, as set forth in theexample type system metadata below:

Name Description title A short string that describes the object - shouldnot contain HTML url Any URL that does not fit one of the other URLtypes color A hex value color such as #FF0000 imageUrl A URL pointing toa full sized image feedUrl A URL pointing to an RSS/ATOM feeddescription A description of the object - can contain HTML of any lengthlatitude A latitude value in decimal format longitude A longitude valuein decimal format thumbnailUrl A URL pointing to a thumbnail imagelocation A string that represents an address custom A custom object thatneeds to be declared in the manifest file of that block videoUrl A URLpointing to a video file - should not be a flash video, but rather theactual video that could be played in any viewer ipAddress An IP addressname The name of something - should be short and not contain HTMLfirstName The first (given) name of a person lastName The last (family)name of a person emailAddress An email address phoneNumber A phonenumber; should include country code city The name of a city state Thename of a state, US only countryOrRegion The name of a country or regionzipCode The ZIP code of a location, US only ISBN An InternationalStandard Book Number (ISBN) UPC An Universal Product Code (barcode)number stockSymbol A stock ticker symbol

Among other aspects, the metadata may be used to augment componentfunctions by providing additional information that can be used by theprogramming environment and runtime to enforce constraints, set defaultvalues, and so on. The following example describes how a JavaScriptimplementation of a function getGeotaggedPhotos (Table 1) is paired withXML metadata (Table 2). Note how the JavaScript function calls for textand a number, which are described in more depth in the XML (in the inputname=“text” and input name=“number” blocks, respectively).

TABLE 1 (JavaScript Function): TestXClass.prototype.getGeotaggedPhotos =function(text, number, sort) {   var apikey = “{{KeyEnc:_ABC }}”;   varparams = “&sort=“+ (sort || “relevance”) + “&text=geotagged+” +escape(text);   var photos = this._getTestXPhotos(“testX.photos.search”,number, params, apikey);   return photos; };

TABLE 2 (Corresponding XML Metadata): <operationname=“getGeotaggedPhotos” callMode=“auto”>    <description>Get photosthat have a latitude and longitude and have been tagged as“geotagged”.</description>    <inputs>     <input name=“text”required=“true” type=“string”>      <description>text in title,description, or tags</description>     <defaultValue>beach</defaultValue>      <constraints />    </input>     <input name=“number” reguired=“false”type=“nonNegativeInteger”>      <description>maximum number of photos toreturn</description>      <defaultValue>15</defaultValue>     <constraints />     </input>     <input name=“sort”required=“false” type=“testXSortOrder”>      <description>text in title,description, or tags</description>     <defaultValue>relevance</defaultValue>      <constraints>      <constraint mandatory=“true” type=“oneOf”>       <value>relevance</value>        <value>date-posted-asc</value>       <value>date-posted-desc</value>       <value>date-taken-asc</value>       <value>date-taken-desc</value>       <value>interestingness-asc</value>       <value>interestingness-desc</value>       </constraint>     </constraints>     </input>    </inputs>    <outputs>     <outputisArray=“true” type=“custom” object=“Photo” />    </outputs>  </operation>

Table 3 shows an example of the XML metadata for an example service. Inthe example, some of the example-specific terms in use include:

Class Name: abstraction

Namespace URL: www.somedomain.com

Provider Name: PhotoProvider

Provider URL: www.photoprovider.com

In the example, elements such as <providerName>, <keys>, <operations>,<input>, and <constraint> are examples of descriptive metadata. Elementssuch as latitude, longitude, and date are type metadata.

TABLE 3 (XML metadata for an example service): <abstractionxmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”xsi:noNamespaceSchemaLocation=“http://www.somedomain.com/schemas/abstractionschema.xsd”  class=“PhotoClass”> <providerName>PhotoProvider</providerName> <providerUrl>http://www.photoprovider.com/</providerUrl> <providerLogoUrl>/icons/PhotoproviderLogo.png</providerLogoUrl> <abstractionIconUrl>/Photoprovider.png</abstractionIconUrl>  <suggestoutput=“imagedisplay geodisplay” input=“userinput”/>  <keys>  <description />  <signUpUrl>http://www.photoprovider.com/apply/</signUpUrl>   <keyid=“APIKey” whenRequired=“save”>    <name>API Key</name>    <notes />  </key>  </keys>  <operations>   <operation name=“getGeotaggedPhotos”callMode=“auto”>    <description>Get photos that have a latitude andlongitude and have been tagged as “geotagged”.</description>    <inputs>    <input name=“text” required=“true” type=“string”>     <description>text in title, description, or tags</description>      <defaultValue>beach</defaultValue>       <constraints />    </input>     <input name=“number” required=“false”type=“nonNegativeInteger”>      <description>maximum number of photos toreturn</description>      <defaultValue>15</defaultValue>     <constraints />     </input>     <input name=“sort”required=“false” type=“photoproviderSortOrder”>      <description>textin title, description, or tags</description>     <defaultValue>relevance</defaultValue>      <constraints>      <constraint mandatory=“true” type=“oneOf”>       <value>relevance</value>        <value>date-posted-asc</value>       <value>date-posted-desc</value>       <value>date-taken-asc</value>       <value>date-taken-desc</value>       <value>interestingness-asc</value>       <value>interestingness-desc</value>       </constraint>     </constraints>     </input>    </inputs>    <outputs>     <outputisArray=“true” type=“custom” object=“Photo” />    </outputs>  </operation>  </operations>  <objects>   <object name=“Photo”>   <field name=“url” type=“imageUrl” isArray=“false” />    <fieldname=“thumbnailUrl” type=“thumbnailImageUrl” isArray=“false” />   <field name=“originalUrl” type=“imageUrl” isArray=“false” />   <field name=“linkUrl” type=“url” isArray=“false” />    <fieldname=“id” type=“numericId” isArray=“false” />    <field name=“owner”type=“userName” isArray=“false” />    <field name=“title” type=“title”isArray=“false” />    <field name=“longitude” type=“longitude”isArray=“false” />    <field name=“latitude” type=“latitude”isArray=“false” />    <field name=“dateTaken” type=“date”isArray=“false” />   </object>  </objects> </abstraction>

As an example of how such a type system may be used, consider theexample of FIGS. 2 and 3, in which a programmer/developer is using aprogramming environment that uses high-level abstractions to representAPI calls. To the programming environment, each API call comprises aninterface that calls the underlying implementation, along with some(XML) metadata that provides the programming environment with aadditional information, such as the “friendly” name for the API, themethods it supports and the types that those methods expect as input,the return values the API will give, and possibly documentation for theAPI.

As represented in the example flow diagram of FIG. 2 via steps 200 and202 and in FIG. 3, the programmer drags an abstract representation(icon) 330 (FIG. 3) of an underlying API onto a design surface 332. Notethat other user actions (e.g., remove an icon, exit the programmingenvironment and so on) are not shown in FIG. 2 for purposes of brevity.

In response to placing the icon, as represented by steps 204 and 206,the programming environment 102 loads JavaScript and associated metadatafrom the data store (or stores) of metadata 110, 112. More particularly,in this example, the action of dragging and dropping the icon 330 ontothe programming environment's design surface 332 causes the programmingenvironment 102 to load the API's corresponding XML metadata (as well asthe associated JavaScript programming logic), which enables theprogramming environment 102 to load further UI (step 210, e.g., via thedescriptive output mechanism 122) and set up the environment for futureinteractions between this API and other APIs (step 210).

The API may then be connected to another API, as represented by step212; note that this typically requires further user interaction, (notexplicitly shown). If so, then the programming environment may use themetadata as desired, such as for matching types across APIs, providingdocumentation, and so forth, as generally represented via step 214.

Thus, in a programming environment that uses a programming language inwhich different interfaces are interconnected, the metadata provides aflexible, well-understood type system that enables the interfaces tosmoothly connect with each other and with the programming environment.For example, the metadata system augments JavaScript so that theprogramming environment can provide more information to itself, to theprogrammer, and/or even to end users (e.g., for rich debugging). Themetadata system is flexible and extensible, which at the same time, iscapable of recognizing specific, pre-set data types.

Exemplary Operating Environment

FIG. 4 illustrates an example of a suitable computing and networkingenvironment 400 on which the examples of FIGS. 1-3 may be implemented.The computing system environment 400 is only one example of a suitablecomputing environment and is not intended to suggest any limitation asto the scope of use or functionality of the invention. Neither shouldthe computing environment 400 be interpreted as having any dependency orrequirement relating to any one or combination of components illustratedin the exemplary operating environment 400.

The invention is operational with numerous other general purpose orspecial purpose computing system environments or configurations.Examples of well known computing systems, environments, and/orconfigurations that may be suitable for use with the invention include,but are not limited to: personal computers, server computers, hand-heldor laptop devices, tablet devices, multiprocessor systems,microprocessor-based systems, set top boxes, programmable consumerelectronics, network PCs, minicomputers, mainframe computers,distributed computing environments that include any of the above systemsor devices, and the like.

The invention may be described in the general context ofcomputer-executable instructions, such as program modules, beingexecuted by a computer. Generally, program modules include routines,programs, objects, components, data structures, and so forth, whichperform particular tasks or implement particular abstract data types.The invention may also be practiced in distributed computingenvironments where tasks are performed by remote processing devices thatare linked through a communications network. In a distributed computingenvironment, program modules may be located in local and/or remotecomputer storage media including memory storage devices.

With reference to FIG. 4, an exemplary system for implementing variousaspects of the invention may include a general purpose computing devicein the form of a computer 410. Components of the computer 410 mayinclude, but are not limited to, a processing unit 420, a system memory430, and a system bus 421 that couples various system componentsincluding the system memory to the processing unit 420. The system bus421 may be any of several types of bus structures including a memory busor memory controller, a peripheral bus, and a local bus using any of avariety of bus architectures. By way of example, and not limitation,such architectures include Industry Standard Architecture (ISA) bus,Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, VideoElectronics Standards Association (VESA) local bus, and PeripheralComponent Interconnect (PCI) bus also known as Mezzanine bus.

The computer 410 typically includes a variety of computer-readablemedia. Computer-readable media can be any available media that can beaccessed by the computer 410 and includes both volatile and nonvolatilemedia, and removable and non-removable media. By way of example, and notlimitation, computer-readable media may comprise computer storage mediaand communication media. Computer storage media includes volatile andnonvolatile, removable and non-removable media implemented in any methodor technology for storage of information such as computer-readableinstructions, data structures, program modules or other data. Computerstorage media includes, but is not limited to, RAM, ROM, EEPROM, flashmemory or other memory technology, CD-ROM, digital versatile disks (DVD)or other optical disk storage, magnetic cassettes, magnetic tape,magnetic disk storage or other magnetic storage devices, or any othermedium which can be used to store the desired information and which canaccessed by the computer 410. Communication media typically embodiescomputer-readable instructions, data structures, program modules orother data in a modulated data signal such as a carrier wave or othertransport mechanism and includes any information delivery media. Theterm “modulated data signal” means a signal that has one or more of itscharacteristics set or changed in such a manner as to encode informationin the signal. By way of example, and not limitation, communicationmedia includes wired media such as a wired network or direct-wiredconnection, and wireless media such as acoustic, RF, infrared and otherwireless media. Combinations of the any of the above may also beincluded within the scope of computer-readable media.

The system memory 430 includes computer storage media in the form ofvolatile and/or nonvolatile memory such as read only memory (ROM) 431and random access memory (RAM) 432. A basic input/output system 433(BIOS), containing the basic routines that help to transfer informationbetween elements within computer 410, such as during start-up, istypically stored in ROM 431. RAM 432 typically contains data and/orprogram modules that are immediately accessible to and/or presentlybeing operated on by processing unit 420. By way of example, and notlimitation, FIG. 4 illustrates operating system 434, applicationprograms 435, other program modules 436 and program data 437.

The computer 410 may also include other removable/non-removable,volatile/nonvolatile computer storage media. By way of example only,FIG. 4 illustrates a hard disk drive 441 that reads from or writes tonon-removable, nonvolatile magnetic media, a magnetic disk drive 451that reads from or writes to a removable, nonvolatile magnetic disk 452,and an optical disk drive 455 that reads from or writes to a removable,nonvolatile optical disk 456 such as a CD ROM or other optical media.Other removable/non-removable, volatile/nonvolatile computer storagemedia that can be used in the exemplary operating environment include,but are not limited to, magnetic tape cassettes, flash memory cards,digital versatile disks, digital video tape, solid state RAM, solidstate ROM, and the like. The hard disk drive 441 is typically connectedto the system bus 421 through a non-removable memory interface such asinterface 440, and magnetic disk drive 451 and optical disk drive 455are typically connected to the system bus 421 by a removable memoryinterface, such as interface 450.

The drives and their associated computer storage media, described aboveand illustrated in FIG. 4, provide storage of computer-readableinstructions, data structures, program modules and other data for thecomputer 410. In FIG. 4, for example, hard disk drive 441 is illustratedas storing operating system 444, application programs 445, other programmodules 446 and program data 447. Note that these components can eitherbe the same as or different from operating system 434, applicationprograms 435, other program modules 436, and program data 437. Operatingsystem 444, application programs 445, other program modules 446, andprogram data 447 are given different numbers herein to illustrate that,at a minimum, they are different copies. A user may enter commands andinformation into the computer 410 through input devices such as atablet, or electronic digitizer, 464, a microphone 463, a keyboard 462and pointing device 461, commonly referred to as mouse, trackball ortouch pad. Other input devices not shown in FIG. 4 may include ajoystick, game pad, satellite dish, scanner, or the like. These andother input devices are often connected to the processing unit 420through a user input interface 460 that is coupled to the system bus,but may be connected by other interface and bus structures, such as aparallel port, game port or a universal serial bus (USB). A monitor 491or other type of display device is also connected to the system bus 421via an interface, such as a video interface 490. The monitor 491 mayalso be integrated with a touch-screen panel or the like. Note that themonitor and/or touch screen panel can be physically coupled to a housingin which the computing device 410 is incorporated, such as in atablet-type personal computer. In addition, computers such as thecomputing device 410 may also include other peripheral output devicessuch as speakers 495 and printer 496, which may be connected through anoutput peripheral interface 494 or the like.

The computer 410 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer480. The remote computer 480 may be a personal computer, a server, arouter, a network PC, a peer device or other common network node, andtypically includes many or all of the elements described above relativeto the computer 410, although only a memory storage device 481 has beenillustrated in FIG. 4. The logical connections depicted in FIG. 4include one or more local area networks (LAN) 471 and one or more widearea networks (WAN) 473, but may also include other networks. Suchnetworking environments are commonplace in offices, enterprise-widecomputer networks, intranets and the Internet.

When used in a LAN networking environment, the computer 410 is connectedto the LAN 471 through a network interface or adapter 470. When used ina WAN networking environment, the computer 410 typically includes amodem 472 or other means for establishing communications over the WAN473, such as the Internet. The modem 472, which may be internal orexternal, may be connected to the system bus 421 via the user inputinterface 460 or other appropriate mechanism. A wireless networkingcomponent 474 such as comprising an interface and antenna may be coupledthrough a suitable device such as an access point or peer computer to aWAN or LAN. In a networked environment, program modules depictedrelative to the computer 410, or portions thereof, may be stored in theremote memory storage device. By way of example, and not limitation,FIG. 4 illustrates remote application programs 485 as residing on memorydevice 481. It may be appreciated that the network connections shown areexemplary and other means of establishing a communications link betweenthe computers may be used.

An auxiliary subsystem 499 (e.g., for auxiliary display of content) maybe connected via the user interface 460 to allow data such as programcontent, system status and event notifications to be provided to theuser, even if the main portions of the computer system are in a lowpower state. The auxiliary subsystem 499 may be connected to the modem472 and/or network interface 470 to allow communication between thesesystems while the main processing unit 420 is in a low power state.

CONCLUSION

While the invention is susceptible to various modifications andalternative constructions, certain illustrated embodiments thereof areshown in the drawings and have been described above in detail. It shouldbe understood, however, that there is no intention to limit theinvention to the specific forms disclosed, but on the contrary, theintention is to cover all modifications, alternative constructions, andequivalents falling within the spirit and scope of the invention.

What is claimed is:
 1. A method comprising: providing a set of metadataidentifying a data type for each programming language code component ofa plurality of programming language code components that are written ina dynamically-typed programming language; detecting a connection of agraphical representation of a first programming language code componentonto a user interface surface in a development environment, theplacement graphically connecting the graphical representation of thefirst programming language code component to at least one graphicalrepresentation of a second programming language component of theplurality of the programming language code components; validating usageof the first programming language code component based on a data typespecified by a first set of metadata for the first programming languagecode component; and inserting executable code into the first programminglanguage component that converts one data type to an appropriate typefor input or output to provide the first set of metadata to a runtimesystem for enhanced type matching during execution.
 2. The method ofclaim 1 wherein detecting the usage of the first programming languagecode component comprises providing a graphical user interface forselecting and interacting with the first programming language codecomponent.
 3. The method of claim 1 wherein accessing the sets ofmetadata to select a selected set of metadata occurs in response todetecting the placement.
 4. The method of claim 1 wherein using thefirst set of metadata in conjunction with the first programming languagecode component comprises validating a constraint associated with avalue, providing a value with default data, validating a value's type,or determining whether a value is required, or any combination ofvalidating a value's constraint, providing a value with default data,validating a value's type, or determining whether a value is required.5. The method of claim 1 wherein the first programming language codecomponent is connected to output information for input by anothercomponent, and wherein using the first set of metadata comprisesdetermining whether a type of information output by the selectedprogramming language code component is appropriate for input by theother component.
 6. The method of claim 1 wherein the first programminglanguage code component is connected to input information output byanother component, and wherein using the first set of metadata comprisesdetermining whether a type of information output by the other componentis appropriate for input by the first programming language codecomponent.
 7. The method of claim 1 wherein using the selected set ofmetadata comprises providing descriptive information corresponding tothe selected programming language code component.
 8. The method of claim1 wherein in response to the placement, assessing a provided set ofmetadata specifying the data type for the first programming languagecode component.
 9. An apparatus comprising: a runtime preparation systemcoupled to a design surface by which programming code is developed viaplacement of icons, the icons comprising graphical representations ofreusable components of the programming code, the plurality of reusablesoftware components programmed in a dynamically-typed programminglanguage; a development environment configured to access sets ofmetadata, each set of metadata to identify a data type corresponding toa component of the plurality of reusable components, and validate usageof a first reusable software component based on a data type identifiedin a corresponding first set of metadata in response to placement of afirst icon corresponding to a first reusable software component on thedesign surface in connection with a second icon representing a secondreusable software component; a runtime system configured to run theprogramming code and use the first set of metadata to validate executionof the programming code at runtime by performing enhanced type matchingduring execution, including inserting executable code into the selectedprogramming language component that converts one data type to anappropriate type for input or output; and the development environmentoperative to provide program metadata or executable code, or bothprogram metadata and executable code for the programming code, to theruntime system.
 10. The apparatus of claim 9, wherein the runtime systemcomprises an interpreter that interprets the program metadata and anengine that runs the interpreter or the executable code.
 11. The systemof claim 9 wherein the part of the programming code comprises a softwarecomponent having a defined interface for coupling to at least one othersoftware component.
 12. The system of claim 11 wherein the softwarecomponent is represented as an icon, wherein the programming code isdeveloped in part by placing the icon on a design surface of the userinterface, and wherein the first set of metadata is selected uponplacing the icon.
 13. The system of claim 9 further comprising typerules and logic that validates the part of the programming code basedupon type data in the corresponding first set of metadata.
 14. Thesystem of claim 9 wherein the first set of metadata comprises at leastsome data defined according to an extensible markup language (XML)schema.
 15. The system of claim 9 wherein the programming code comprisesJavaScript, European Computer Manufacturers Association (ECMA)Script, orJScript.
 16. The system of claim 9 further comprising a descriptiveoutput mechanism that provides descriptive information with respect tothe part of the programming code, the descriptive information based uponinformation maintained in the corresponding selected set of metadata.17. An article of manufacture comprising a computer-readable storagemedium containing processor-executable instructions that, when executedby a system, cause a system to: provide a design surface comprisingicons representing software components programmed in a dynamically-typedprogramming language; detect a selection of an icon representing asoftware component based on a first set of data and connection of theicon to at least one other icon of the design surface; use the secondset of data to provide descriptive information, and validate usage ofthe software component based on the data type identification in thethird set of data to provide a type system for the software componentthat does not rely upon inference by enforcing at least one constraint,setting a default value, and validating at least one type correspondingto at least one data value of the software component by insertingexecutable code into the software component that converts one data typeto an appropriate type for input or output during execution of thesoftware component.
 18. The article of claim 17 wherein the second setof data comprises text, or a reference to text, graphical data that maybe rendered via a user interface, or a reference to graphical data thatmay be rendered via a user interface, or any combination of text, areference to text, graphical data or a reference to graphical data. 19.The article of claim 17 wherein the third set of data comprises typedata corresponding to a type of data that the software component inputs,outputs or both inputs and outputs.
 20. The article of claim 17 whereinthe third set of data comprises at least one of a constraint associatedwith a value, at least one of default data for a value, at least one oftype information for a value, or data that indicates whether a value isrequired, or any combination of a constraint associated with a value,default data for a value, type system information for a value, or atleast one of data that indicates whether a value is required.